Advanced communication devices (also denoted user equipment, UE), such as smart phones, are able to handle multiple active connections (radio access bearers, RABs) simultaneously and a user is for example able to make a phone call while at the same time downloading data. A circuit switched (CS) core network (CN) may handle one type radio access bearers and a packet switched (PS) core network may handle another type of radio access bearers. It may happen that a handover in both the CS domain and in the PS domain is needed simultaneously for a user.
Current behavior is that if handover to one domain fails then the other domain shall also be failed by the source radio access network (RAN). Assuming for example that a communication device is connected to a source RAN and has services on two domains, e.g. CS domain and PS domain; if the communication device is denied access e.g. in the PS domain due to admission control failure, it will not get service and will not be reachable/available at the target location on the PS domain. In accordance with current standard the communication device then fails the handover attempt in both domains (as specified in TS 25.413v11.2.0, section 8.6.5), even if the other domain (e.g. the CS domain in the above example) could have been handed over successfully.
FIG. 1 illustrates these current procedures in case of handover failure of one domain, and in particular an example of intra UMTS Terrestrial Radio Access Network (UTRAN) handover. FIG. 1 thus shows the handling of multiple (two in the illustrated case) domain handovers in case of relocation/handover failure in one domain according to current specifications (refer to TS 250.413v11.2.0). The existing solution is based on the specification TS 25.413v11.2.0, section 8.6.5, which quotes:
“If the source RNC receives a RELOCATION PREPARATION FAILURE message from the CN, the RNC shall initiate the Relocation Cancel procedure on the other Iu signaling connection for the UE if the other Iu signaling connection exists and if the Relocation Preparation procedure is still ongoing or the procedure has terminated successfully in that Iu signaling connection, except for the case where the relocation is to a target Closed Subscriber Group (CSG) cell where the UE is a non-member of the target CSG, and where there is at least one of the RABs that has a particular ARP value (see TS 23.060 [21]) in the other domain.”
Returning to FIG. 1; the source radio network controller (RNC) 1 decides to perform both CS domain handover and PS domain handover for a communication device 10 (box indicated by reference numeral 7). The CS domain handover is successful (box indicated by reference numeral 8). The source RNC 1 sends a RELOCATION REQUIRED/REQUEST for the PS domain to the target RNC 2 via the source PS CN 4 (arrows A1). This handover fails (box indicated by reference numeral 9). The source RNC 1 receives a RELOCATION PREPARATION FAILURE/RELOCATION FAILURE from the target RNC 2 via the target PS core network (CN) 6 and source PS CN 4 (arrows A2). The source RNC 1 initiates the Relocation Cancel procedure (arrows A3) as defined in the above-mentioned specification. The target CS CN 5 then acknowledges this relocation cancelling by sending the RELOCATION CANCEL ACKNOWLEDGEMENT (arrow A4).
Failure to cancel the handover e.g. on the CS domain would imply that the communication device 10 is registered in the target coverage area for the CS domain, but cannot get registered (due to lack of granted access) in the target coverage area for the PS domain (for which the handover failed). At the same time, the source CN 4 of the PS domain believes that the communication device 10 is still under its own coverage, due to the fact that the PS handover failed (i.e. source CN 4 received a Handover/Relocation Failure message). As a result, the communication device 10 will not be reachable in the PS domain either because any Routing Area Attempts in such domain will fail.
In RAN3#77 and RAN3#78 a number of contributions (R3-122171, R3-122668 and R3-122669) were proposed attempting to address the technical problem described above. The suggested solutions in these papers propose to let one domain handover succeed, while the second domain handover is failed, without addressing the possibility that the communication device might become unreachable in the failed domain.